Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_0399/295

Internet Message Format | 1994-08-27 | 7.1 KB

Date: Sat, 4 Jun 94 20:43 BST-1
From: Andre Willey <[e-mail]>
Subject: DEFAULT.SYS: Draft proposal, 4/6/94
To: [e-mail]
Message-Id: <[e-mail]>
Precedence: bulk



I have added the various new suggestions from the group to this proposal, and
formalised one or two things. Comments and discussion on this new proposal are
welcome. When everyone is finally happy, we can put it to a vote to formally
ratify it. Is anyone from Atari US/US/Germany on this list as yet? I think we
need to contact them for their input if we are to get anywhere with either of
the two proposals currently being discussed.




  Proposal for the creation of a system-wide 'default settings' lookup file
  =========================================================================

          Andre Willey ([e-mail])    6 Jun 1994


It is proposed that we designate a new system file, to be called DEFAULT.SYS,
which will be used to configure all application programs so that they use a
common set of keyboard shortcuts, as defined by the user. In the longer term,
this same file will be easily extensible to support other system default
settings - but for now let's just get the keyboard stuff sorted out!

The DEFAULT.SYS file will be located in the root directory of the current boot
drive, and may be accessed by any program in order to configure itself to the
user's wishes. If such a file is not found, the default keys should be set up
as per the general keyboard shortcuts proposal (managed by Ofir Gal).


General file format
===================

DEFAULT.SYS will be a plain ASCII text file, using <CR><LF> line ends, which
can be edited manually by the user, or optionally via an editor program or CPX.

The first line will be a unique header, to indicate that what follows are a
series of keyboard shortcut lines. I suggest:

  # Keyboard_Shortcuts      ; Optional Comments (e.g. language translations)

All subsequent lines, until another definition line starting with '#' is found,
will comprise either a simple comment line (starting with ';'), or a keyboard
shortcut definition of the following form:

  0 ^Q ; Quit
  ^  ^   ^
  |  |   Comment text (not parsed; can be any language, or indeed several)
  |  |
  |  Keypress (user-editable. Uses syntax listed below)
  |
  Code number, unique to a given operation (e.g. 0 for Quit, 1 for Close
  Window, etc.)

[Note: The series of actual code numbers will not be created until the default
keyboard shortcuts list is approved, at which stage each one will be assigned a
unique code number]


Each application which supports this new system should read the DEFAULT.SYS
file during its installation process. When it finds a "# Keyboard_Shortcuts"
header line (which currently will be the first line of the file, but don't
presume that to be the case for ever) it will parse each subsequent line and
assign the requested keyboard shortcut to the appropriate internal operation.
Not all codes will apply to all types of program, so an application should only
bother parsing those codes which it understands and requires (all other codes
should be ignored). Some programs may only need a couple of shortcuts - perhaps
even just 'Quit' - and it is entirely up to the programmer to decide how many
shortcuts he/she wishes to support.

The application should cease looking for keyboard shortcuts as soon as it comes
across any line starting with a '#' character, or when it reaches the end of
the file. I suggest, for convenience's sake, that we allow for a "# EOF" line,
but at this stage that is implied anyway.


Naming conventions for shortcuts
================================

It is proposed that we use the following terminology to refer to keys (both
within the shortcuts file and in menu entries):

   Tab, Spce, Caps, Ret, Del, Bksp, Esc, Help, Undo, Ins, F1-F10, Clr (Home?)

   Numeric keypad keys should be shown as [1], [2], [+], [-], etc. Thus, to
   conform, Enter should be shown as [Ent], rather than just Enter.

   Arrow keys are shown as the ASCII arrow symbols (ASCII 1-4) within square
   brackets (this avoids clashes with up-arrow for shift and right-arrow for
   submenu, etc.)

   Modifiers: ASCII 1 (up-arrow) for Shift. ^ for Control. ASCII 7 for Alt.
   Modifiers should be displayed in the above order. Alt-Control combinations
   should be avoided wherever possible.


Menu options
============

Ideally, every shortcut that directly represents a menu option should be shown
as part of the text of that same menu item. However, there are going to be some
shortcuts that don't physically fit into menus. This can't be avoided (e.g. a
user sets up Shift-Control-Alt-Undo, or some such). An application should put
shortcuts into its menus *where it has space to do so* - but if it can't for
any reason, just flag that menu option as having a shortcut which doesn't fit.
For the sake of argument, shall we agree on using the ASCII 240 character for
this purpose? If possible, an application should allow up to 6 characters of
space for shortcuts in menus (this is only a guideline; some applications won't
be able to do this).


Clashes
=======

If a user-requested shortcut clashes with another shortcut setting (perhaps for
some 'specialised' internal command for which we don't yet have a shortcut code
defined) the user-requested shortcut should be honoured, and the internal
operation becomes unassigned. i.e. the user's requirements are satisfied first,
the programmer's second.

To help alleviate this problem, application-specific shortcuts (e.g. DTP, MIDI,
Database, etc) will have ranges of numbers assigned for their use only, which
all other types of program should ignore. I propose assigning blocks of 1000
codes (e.g. 0-999 for defaults, 1000-1999 for DTP, etc). This should allow more
than enough entries, and make the divisions more obvious when examining the
file. We need to decide on useful categories, but this could be done later in
the standard and need not hold up the basic default system.

The golden rule for parsing codes should be "if your program doesn't understand
a code, ignore it".

If, for some daft reason, the user tries to assign the same shortcut twice - or
they have used the same code number twice - follow the same rules and throw
away the existing copy and use the new one (i.e. don't write any extra code to
cover this eventuality; treat it like an internally defined code is being
overwritten). Any DEFAULT.SYS editor programs should watch out for and prevent
such internal clashes, though.


Finally
=======

If this standard is to be accepted, we must keep it SIMPLE. Esoteric and
complicated solutions to specific problems probably won't help endear the
system to programmers. If must be easy for the user to understand, and for the
program to handle, or it simply won't get used.

Andre

 +------------------------------------+-------------------------------+
 |            Andre Willey            |  Cygnus Software Development  |
 |  Email: [e-mail]  |  Sutton Coldfield -- England  |
 |   or: ...{mcsun}!uknet!cix!andre   |  Tel:  (UK/[phone]  |
 +------------------------------------+-------------------------------+